Extensible manufacturing/process control information portal server

ABSTRACT

A manufacturing/process control system information access provider architecture is disclosed. Manufacturing/process control system data provider flexibility is achieved through a user-configurable manufacturing/process control information portal server that comprises multiple selectable data provides (sources) and/or data types that a particular data provider accommodates. A user configures the portal server to deliver manufacturing/process control information associated with a controlled process environment, such as a food processing plant floor or an oil refinery reactor, to the user via a browser client over the Internet or a corporate intranet. Furthermore, an extensible architecture is provided that enables adding new components to the portal server. Such extensions include new data sources and new data types/handlers. The new architecture enables a user to select particular ones of the available data handlers and then their associated data sources thereby facilitating customizing the configuration of the portal server to the particular needs/interests of the user.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority of Formey et al. U.S. provisionalapplication Ser. No. 60/232,733, filed on Sep. 15, 2000, entitled“Extensible Manufacturing Portal Server,” the contents of which areexpressly incorporated herein by reference in their entirety includingthe contents and teachings of any references contained therein.

FIELD OF THE INVENTION

The present invention generally relates to the field of computerizedmanufacturing/process control networks. More particularly, the presentinvention relates to systems for providing access by supervisory levelapplications and users to manufacturing/process control information. Thepresent invention concerns the provision of such information frommultiple, potentially differing sources having differing data types.

BACKGROUND OF THE INVENTION

Significant advances in industrial process control technology havevastly improved all aspects of factory and plant operation. Before theintroduction of today's modern industrial process control systems,industrial processes were operated/controlled by humans and rudimentarymechanical controls. As a consequence, the complexity and degree ofcontrol over a process was limited by the speed with which one or morepeople could ascertain a present status of various process statevariables, compare the current status to a desired operating level,calculate a corrective action (if needed), and implement a change to acontrol point to affect a change to a state variable.

Improvements to process control technology have enabled vastly largerand more complex industrial processes to be controlled via programmedcontrol processors. Control processors execute control programs thatread process status variables and execute control algorithms based uponthe status variable data and desired set point information to renderoutput values for the control points in industrial processes. Suchcontrol processors and programs support a substantially self-runningindustrial process (once set points are established).

Notwithstanding the ability of industrial processes to operate under thecontrol of programmed process controllers at previously established setpoints without intervention, supervisory control and monitoring ofcontrol processors and their associated processes is desirable. Suchoversight is provided by both humans and higher-level control programsat an application/human interface layer of a multilevel process controlnetwork. Such oversight is generally desired to verify proper executionof the controlled process under the lower-level process controllers andto configure the set points of the controlled process.

Various data input/output servers, including for example data accessservers, facilitate placing process control data (both reading andwriting) within reach of a variety of higher-level monitor/controlclient applications. During the course of operation, process controllersgenerate status and control information concerning associated processes.The controllers' process status and control information is stored withinprocess control databases and/or distributed to a number of locationswithin the process control network. Other process information isgenerated/stored within field devices (e.g., intelligent transmitters)having digital data communication capabilities. The process informationis retrieved from the process control databases and field devices bydata access servers for further processing/use by the process controlsystem. For example, the data access servers provide the retrievedinformation to a variety of client applications providing high-levelcontrol and monitoring (both human and computerized) services.

In systems containing data input/output servers, the high-level controland monitoring applications rely upon the proper operation of theservers to provide the data upon which such applications rely fordecision making. The information includes real-time process variablevalues, alarms, etc. Data input/output servers are implemented in anumber of forms. In some systems, a single data access server operatesupon a single node on a computer network from which higher-levelsupervisory control is implemented. In other systems, multiple dataaccess servers are located upon a local area network, and the multipledata access servers are accessed by supervisory-level applicationsrunning on other nodes on a local control network. In yet other systems,access to process control information/resources is achieved viatemporary sessions established via a wide area network link. Oneparticular example is data access provided via an Internet/intranetportal server.

A portal site is an Internet/intranet site that provides access to avariety of information from potentially many sources. Portal sites,referred to as vertical portals, are sometimes designed to provideaccess to a particular type of information. Portal servers handle usertraffic at portal sites and provide user access over theInternet/intranet to the variety of data sources exposed by the portalsite. Users generally access the portal site via remote computersexecuting general browser software such as the well known MICROSOFTINTERNET EXPLORER. Through the browsers the users access the datasources exposed by the portal site/server.

Portal servers provide a wide variety of services. One example of such aservice is “content accessibility” that facilitates connectivity toinformation sources and content providers. Content includes: onlinedocuments, libraries, databases, and government information. Suchcontent can be located over a wide geographic area, but is connected viaa network structure (e.g., the Internet). Another example of a portalservice is a search engine that enables users to locate particularinformation within a vast amount of available content.

A portal server often maintains an index to enhance performance ofsearches. Another portal service is visualization of available services(e.g., displaying various features available to users). A second aspectof visualization is displaying documents and information retrieved atthe request of a user. Yet another portal server function is providingaccess to users from many parts of the world via the World Wide Web.Such access includes both domestic and foreign users. A last example ofa portal function is support for personalization. A portal is used bymany different people for many purposes. Portal servers store userprofile information to enhance user experiences.

An advantage of a portal server approach to accessing process controlinformation/resources is the ability of users to gain access fromvirtually any location in the world. Such access enables specialists(both human and programmed) to obtain access to and provide supervisoryservices without having to be physically present on themanufacturing/industrial plant. Such accessibility can save anenterprise considerable time and costs and avoid travel delays. Widearea network access of the type supported by a portal server alsoenables centralized, coordinated and highly integrated control of anenterprise spread over a relatively wide geographic area.Notwithstanding the significant benefits of providing Web access to aprocess control network, significant challenges are faced with regard toconnecting such systems to the manufacturing/process control systemswith which they communicate, and there is a substantial cost in time andeffort to link the various resources to manufacturing/process controlinformation portal servers.

Yet another obstacle in the deployment and maintenance ofmanufacturing/process control information portal servers is the presenceof a wide variety of information types. Installing a new portal serverwhen a new data transmission protocol or format is needed can greatlydisrupt operation of the manufacturing/process control system for whichit provides its services.

Typical portal sites/servers are designed to provide virtually the sameresources to a very large audience. In a process control environment,information sources and types are tailored to many different andsignificantly smaller groups of individuals. The various informationtypes require different handlers. Even within an enterprise, personshaving differing roles will have an interest in viewing data ofdiffering types from differing sources.

SUMMARY OF THE INVENTION

The present invention offers a flexible manufacturing/process controlinformation provider architecture. This flexibility is achieved througha user-configurable manufacturing/process control information portalserver that comprises multiple selectable data types (handlers) and datasources that a particular selected data handler accommodates. A userconfigures the portal server to deliver manufacturing/process controlinformation associated with a controlled process environment such as afood processing plant floor or an oil refinery reactor to the user via abrowser client over the Internet or a corporate intranet.

Furthermore, an extensible architecture is provided that enables addingnew components to the portal server. Such extensions include new datasources, new data types, and new generic data handlers. The newarchitecture enables a user to select particular ones of the availabledata handlers and then their associated data sources therebyfacilitating customizing the configuration of the portal server to theparticular needs of the user.

BRIEF DESCRIPTION OF THE DRAWINGS

The appended claims set forth the features of the present invention withparticularity.

The invention, together with its objects and advantages, may be bestunderstood from the following detailed description taken in conjunctionwith the accompanying drawings of which:

FIG. 1 is a schematic drawing depicting an exemplary process controlenvironment for the present invention wherein a manufacturing/processcontrol network includes a portal server that provides a variety ofportal services to browser clients;

FIG. 2 is a schematic drawing of the general components making up anexemplary manufacturing/process control portal server system;

FIG. 3 is a block diagram listing fields that are included in providertable records within a configuration database;

FIG. 4 is a screen shot of an exemplary graphical user interface (GUI)used for defining a new data source (provider) to be stored as a newtable entry in a configuration database;

FIG. 5 is a schematic drawing of the details of an exemplary runtimedatabase (RDB);

FIG. 6 is a block diagram listing the methods of an exemplary IRunTimeDBinterface exposed by an RDB for use by a data exchange (DE);

FIG. 7 is a block diagram listing methods of an exemplary IOIteminterface exposed by an RDB for use by a DE;

FIG. 8 is a block diagram listing methods of an exemplary IOItemListenerinterface exposed by a DE for use by an RDB;

FIG. 9 is a block diagram listing methods of an exemplary IOutpostinterface exposed by an HTTP Client Interface (HCI) for use by an RDB;

FIG. 10 is a block diagram listing methods of an exemplaryIOutpostSessionListener interface exposed by an RDB for use by an HCI;

FIG. 11 is a dataflow diagram that depicts a sequence of calls andactions between a client (portal server HCI) and a plant server over anestablished HTTP connection;

FIG. 12 is a schematic drawing of an exemplary embodiment of a portalserver framework;

FIG. 13 is a block diagram of an XML schema listing data sources andtheir associated handlers within a data provider registry;

FIGS. 14 and 15 are screen shots of an exemplary GUI for registering adata provider;

FIG. 16 is a block diagram listing methods of an exemplary connectionobject;

FIG. 17 is a block diagram listing method of an exemplary commandobject;

FIG. 18 is a block diagram listing methods supported by a framework Webservice handler;

FIG. 19 is a sequence diagram depicting an exemplary set of stepsexecuted between clients and a framework Web service handler during thecourse of a user session;

FIG. 20 is a block diagram depicting exemplary relationships among threeobject classes within a framework Web service handler;

FIG. 21 is a block diagram listing exemplary methods implemented withina data provider handler; and

FIG. 22 is a block diagram showing an exemplary SQL provider handlerclass structure and the relationships among the classes in a COMcomponent.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

The present invention concerns an extensible manufacturing/processcontrol information portal server that enables users to visualize plantfloor information coming from a variety of systems and databases (e.g.,Wonderware's InTouch systems, InTouch/AlarmSuite alarm databases, I/Oservers, and Industrial SQL) over the Internet or an intranet via abrowser (e.g., IE 5). The extensible manufacturing/process controlportal server supports interactive HTML pages in XML, applying an XSLtransformation, and dynamically rendering VML on a client machine (aswell as providing animation updates from live process data sources). Theportal server allows users to generate ad hoc queries of a real-timeprocess control SQL database to produce trends and reports viewable witha browser client such as MICROSOFT'S INTERNET EXPLORER. In addition, theportal server supports Internet enabled ActiveX controls and a SQLserver report tool. The manufacturing/process control portal serversupports bi-directional communications between browser-clients and adata provider associated with an observed manufacturing/process controlsystem.

An exemplary manufacturing/process control information portal serverdescribed herein below provides a user configurable data handler anddata source designation interface. First, a user designates a type ofinformation (associated with a particular data handler). Second, theuser designates a source of information of the selected informationtype. For example, a user can select an “alarm” data type/handler.Thereafter, the user selects a portion of the plant (i.e., aninformation source) for which data is supplied. Thereafter, the portalserver is configured, through the instantiation of appropriate objects,to deliver the configured data to the requesting browser client. Theuser can be either human or a machine submitting appropriate commands tothe portal server configuration facilities.

An exemplary manufacturing/process control information portal serverincorporating the present invention provides an extensible portal serverarchitecture enabling developer/users to extend the capabilities of thesystem. A first form of such extension comprises the ability of a userto re-configure the portal server to provide information from adesignated resource. A second form of extending the portal server'scapabilities is adding new data handlers to support new forms/formats ofdata that are used to provide information from connected sources.

The extensible manufacturing/process control portal server of thepresent invention provides a highly flexible infrastructure foraggregating plant floor information (for client applications) anddisseminating data back to, for example, a manufacturing plant floor.The access is provided to client-users via the Internet and intranets.The extensible architecture and technology allow users to add new datasources to the main portal server. The extensible architecture alsofacilitates adding new data handlers.

In general, the extensible architecture is facilitated by a set ofgeneric interface definitions that facilitate the creation ofsource-specific and handler-specific object components. Each of theadded components (handlers and sources) is carried out by an objectclass (or subclass) defined according to the set of generic interfacedefinitions. In an embodiment of the invention, server developers areaided by a toolkit which simplifies the process for developing newhandlers and sources that are added to the extensible portal servers.The toolkits also ensure that the added components comply withrequirements of the generic interface definitions.

Turning to FIG. 1, an exemplary portal server arrangement isschematically depicted. A portal server 10 provides portal services to amanufacturing/process control environment. That environment consists ofa database server 20 and a data access server 30. The data access server30 in turn connects to process control equipment 40. The portal server10 provides its services to browser clients at locally connectedworkstations 50 and, via the Internet 60 or a proprietary network, atremote workstations 70. The connected workstations 50 and remoteworkstations 70 connect to the resources of the portal server 10 viabrowser clients such as, for example, MICROSOFT's INTERNET EXPLORER. Theabove network is merely a simple example of an application of thepresent invention. Those skilled in the art will readily appreciate thebroad spectrum of network topologies and environments in which amanufacturing/process control information portal server embodying thepresent invention can operate.

Turning to FIG. 2, components of a first exemplary extensible portalserver architecture are illustratively depicted. The portal server 100is interposed between sources of manufacturing and process controlinformation of various information types 110 and a set of browserclients 120. Such clients 120 can be thin clients running little or noapplication-specific software. The clients 120, executing browsers andgeneric browser support software, rely upon the processing capabilitiesof the portal server to provide the manufacturing and process controlinformation in a browser-ready format. The browser clients 120 generatethe corresponding display information and transmit user selections backto the portal server 100. The portal server 100 also provides aconfiguration interface depicted herein below with reference to FIG. 4that enables a user to add a new data source to a set of data sourcesfrom which the portal server 100 obtains data on behalf of the browserclients 120. Such configuration information is stored within aconfiguration database 150 in an manner such as the exemplary recorddepicted herein below with reference to FIG. 3.

The information sources (typically servers—but not depicted in theFigure) of various types 110 supply information to the portal server 100in a variety of formats. As indicated in FIG. 2, such types includehistory (archived process control information), alarms, graphicsapplications (e.g., trend graphs), real-time manufacturing/processcontrol system data supporting remote monitoring of a system, andbusiness information (generally stored within databases). The portalserver includes a data access subsystem 125 that is responsible forretrieving and sending data (in real-time) between the portal server100's browser client interface framework and an enterprise's sources ofinformation (e.g., plant floor process control status and controlinformation). The data access sub-system 125 (see FIG. 3) comprises anextensible set of data handlers 130 that process the informationrendered by the information sources 110 in specialized formats. The datahandlers include, for example, history and alarm handlers. Other datahandlers are associated with particular client data exchange protocolformats such as OPC, SuiteLink, and DDE. Another identified handlerprocesses XML. A custom block 140 is intended to depict theextensibility of the set of data handlers 130 which supports theaddition of new (custom) configurations of data handlers after initialinstallation. This is facilitated by an open architecture and a genericinterface definition between the data handlers and a portalframework-client interface that renders web pages to the requestingclients based upon corresponding information provided by particular datasources via corresponding ones of the data handlers 130.

The portal server 100 includes a number of sub-systems. Configuration ofthe portal server, including user-configuration described herein, issupported by a configuration database 150. The configuration databaseincludes a data_providers table that stores connection informationlinking data providers (external data sources) to the portal server 100that in turn connects to a requesting client. The data providers tableis accessed by a “Data Source Configuration” web page presented to usersof the portal server 100 (see FIGS. 3 and 4). In an enhanced embodimentof the invention a second configuration interface enables users to addnew data handlers (for handling new data types) to the portal serversystem. When a new data handler is added to the portal server 100, a setof registration information (see FIG. 13 discussed herein below) isstored within a data handlers registry that is separate and distinctfrom the data_providers table maintained within the configurationdatabase 150.

In some cases client browsers need plug-in components to view portalinformation. For example, if process graphics contain ActiveXcomponents, then the ActiveX components need to be downloaded. This taskis accomplished by a deployment manager 151. The deployment manager 151combines all files that must be downloaded, registers the components onclient machines, and initializes them.

A security administration sub-system 152 facilitates limiting access toparticular resources. The security system 152 enforces access rightswith regard to particular resources accessed by identified users. Otherpotential sub-systems include multi-language support and multi-userconcurrent user license management.

Having described an exemplary manufacturing/process control portalserver system, attention is now directed to the extensible/configurableaspects of the portal server system. As mentioned previously hereinabove, the portal server is extensible in that a user can configure anew data provider (source of data) to add to an available set of sourceslisted in the configuration database 150. Turning now to FIG. 3, a setof fields is identified that is included in provider table recordswithin the configuration database 150. An ID field 154 stores a uniquevalue identifying the record within the table of provider records. Thevalue stored in the ID field 154 is system-generated at the time therecord is created. A type field 155 describes the type of data handler(e.g., Alarm, History, Statistics, Real-Time Data) with which this datasource is associated. Thus, when a user selects a particular informationtype (e.g., alarms), all data providers that provide this data type areretrieved and listed for the user's selection.

An alias field 156 stores an alias name for this data handler. ForInternet connection and security, it is advisable to hide original namesthrough the use of alias names. A server field 157 holds a name of aserver that is acting as the data provider. A DB field 158 holds thedatabase name for the data provider. A User field 159 and password field160 hold the system username and password for the data provider (ifneeded to access the server). The appropriate data handler uses the nameand password to login on to a database server. Passwords are encryptedbefore they are stored. A description field 161 holds the informationregarding a data handler description. A contact field 162 holdsinformation regarding a system administrator description for thisprovider. Finally, a default server field 163 stores a default serveridentity. If a user has configured many data providers, the user picks aparticular server as a default server for user queries.

Having described exemplary fields for a data provider record, attentionis directed to FIG. 4 wherein an exemplary graphical user interface(GUI) is provided for a user to define a new data source (provider) tobe stored as a new table entry in the configuration database 150. Thegraphical user interface includes a set of tabs 166 labeled Alarm,InSQL, Admin, and Create New. The Alarm and InSQL tabs correspond toparticular data handlers that are presently installed on the extensibleportal server. When a user selects either of the two data handler tabs,a user interface is generated that includes all data sources thatprovide the selected data type. The Admin tab provides access to avariety of administration data including user activity on the portalserver.

Finally, the Create New tab corresponds to the data source extensibilityfeature of a portal server embodying the present invention. When a userselects the Create New tab, the user interface provides the templatedepicted in FIG. 4, and the user enters data corresponding to thevarious fields of the data provider record depicted in FIG. 3 andexplained herein above. After completing the data source/provider“form”, the user selects the “submit” button to cause the incorporationof the defined data source into the extensible list of data providers.In an enhanced embodiment of the present invention, the extensibility ofthe portal server 100 includes adding new data handlers (discussedfurther herein below).

Turning to FIG. 5, the data access subsystem 125 is depicted in furtherdetail. FIG. 5 depicts the flow of information, via a set of logicallyconnected objects, from a data exchange 182 to an RDB internal classobject and then to an HCI component 170 connected to a plant floorserver 178 for a client session. The data access subsystem 125 includestwo COM components. A first COM component, HCI (HTTP Client Interface)170, sets up an HTTP connection for sending and receiving raw databetween the portal server and a plant floor web server 178. The HCI 170implements an Ioutpost interface 172 for receiving requests from aCrdbSession object 174. The CrdbSession object 174 implements anIoutpostSessionListener interface 176.

The HCI 170 is a lowest-layer component on the data access subsystem 125that is responsible for establishing connection to the server 178. TheHCI 170 uses the http Internet API to open a connection with the server178, then utilizes a post request to communicate with the fsoutpst.dll,an ASAPI extension component, on the server 178. The fsoutpst.dll thenroutes the request to rdbhandler, a service component on the server 178.The HCI 170 internally creates a thread to send a heartbeat to theserver 178 every 200 ms to keep the connection alive and to check forany data available for sending from the server 178.

A second COM component of the data access subsystem 125, a runtimedatabase (RDB) 180, marshals and unmarshals data (allowing it to bepassed to an intended destination) and interacts with a data exchange182. The data exchange 182 performs the task of passing data betweenconnected client browser sessions and the RDB 180 via a designated itemtag established in the runtime database component.

When a user completes designating a source of data, the data exchange(DE) component 182 first creates an instance of CruntimeDB 184 throughthe IRuntimeDB interface 186. Then the DE component 182 calls an AddItemmethod on CruntimeDB 184 to tell the RDB 180 to add a tag to the dataaccess subsystem for a new item. The AddItem method returns an IOIteminterface 190 that allows the DE component 182 to write data back to theweb server 178 via the RDB 180. In order for the DE 182 to receive dataon the tag, it must call the setItemListener method through the IOIteminterface 190 to hand the RDB 180 an IOItemListener interface 192 of theDE 182.

When the DE 182 adds a tag to the data access subsystem 125, the RDB 180creates and queues the messages internally and does not send them to theweb server 178 until a Run method is called through the IRuntimeDBinterface 186 to start a data-writing thread. Each instance of theCrdbSession 174 has an interface pointer and a connection point thatallows it to send and receive to/from the HCI 170.

Connections between the DE 182 and a selected data source are associatedwith sessions. Thus, when the data exchange 182 calls the AddItem methodon CruntimeDB 184 to add a tag item, the RDB 180 internally creates theCRdbSession class object base 174 on the Web server address, user ID,and password. The CrdbSession object 174 then creates a CIOConnectionclass object base 185 on NodeName, App Name, Topic, and Connection Type.Then the CIOConnection object 185 creates a CIOItem object base 187 on atag name. With this design, the CrdbSession object 174 maps to a clientsession on the server, the CIOConnection object 185 maps to a node andapplication, and the CIOItem object 187 maps to a tag on theapplication. Each session on the server can have multiple connections todifferent nodes or applications, and each application can have many tagitems.

Having described the general connection architecture, the followingdescribes data flow from a plant floor data source web server 178 to thedata exchange 182. The HCI component 170 includes an internal threadthat periodically sends out a heartbeat to the server to keep theconnection alive and to determine whether any data is available. Whenthe HCI 170 receives data from the server 178 it passes the data to theRDB 180 component through the IoutpostSessionListener 176 interface(connection point) of the CrdbSession object 174. The RDB 180 passesthis data to its internal class object CliRdbUnMarshallListener 191 tounmarshal the data. Once the data is unmarshalled, it is passed to the(proper) CIOConnection object 185 and then to the CIOItem object 187.The CIOItem object 187 then calls the DE 182 via the IOItemListenerinterface 192 to provide the new tag value to the DE 182.

With regard to data flow from the DE 182 to the plant floor, the DE 182calls a method in the IOItem interface 190 to write the data back to theserver 178. The data travels through an internal class to be marshaledand then to CrdbSession 174. The CrdbSession sends the data value to theHCI 170 via the Ioutpost interface 172.

Having described the general architecture of the connection frameworkwithin the data access component 125 of a portal server embodying thepresent invention, attention is directed to FIGS. 6, 7, 8, 9, and 10that identify each of the methods incorporated into the above-mentionedinterfaces associated with the data access component 125.

The IruntimeDB interface 186 comprises the following methods describedherein below with reference to FIG. 6. A call to AddItem 200 will addanother data item to the session causing the RDB 180 to track this itemfrom a particular data source associated with the session.

HRESULT AddItem([in] BSTR bstrOutpost, [in] BSTR bstrNode, [in] BSTRbstrApp, [in] BSTR bstrTopic, [in] BSTR bstrConnType, [in] BSTRbstrItem, [out, retval] IDispatch **ppIOItem)

Parameters

BstrOutpost—destination server address

bstrUserName—user name for authentication

bstrPassword—password for authentication

bstrNode—nodename

bstr App—Application name

bstrTopic—Topic name

bstrConnType—Connection type

bstrItem—Item name

ppIOItem—Pointer to IOItem interface

The RemoveItem 202 method is called to remove an item from a session.HRESULT RemoveItem([in] BSTR bstrOutpost, [in] BSTR bstrNode, [in] BSTRbstrApp, [in] BSTR bstrTopic, [in] BSTR bstrConnType, [in] BSTRbstrItem)

Parameters

BstrOutpost—destination server address

bstrUserName—user name for authentication

bstrPassword—password for authentication

bstrNode—node name

bstr App—Application name

bstrTopic—Topic name

bstrConnType—Connection type

bstrItem—Item name

The Start 204 method is called to start processing data.

HRESULT Start( )

The Stop 206 method is called to stop processing data.

HRESULT Stop( )

The RemoveAllItems 208 method is called to remove all items associatedwith the session.

HRESULT RemoveAllItems( )

Turning now to FIG. 7 a set of methods associated with the IOIteminterface 190 are summarized by reference to their parameters. First, agetName 210 method retrieves the item name.

HRESULT getName([out] BSTR *bstrName)

Return Value:

BstrName—Item name

A getID 212 method is called to get an item ID.

HRESULT getId([out] int *pId)

Return Value:

pId—Item ID

The remaining methods are largely self-explained by their method namesand associated parameter definitions.

GetItemValueType 214:

HRESULT getitemValueType([out] int *piValue)

Return Value:

PiValue—item value type

GetIntValue 216:

HRESULT getIntValue([out] int*pValue)

Return Value:

pValue—Item integer value

GetRealValue 218:

HRESULT getRealValue([out] float *pfvalue)

Return Value:

pfValue—Item float value

GetStringValue 220:

HRESULT getStringValue([out] BSTR *pbstrValue)

Return Value:

pbstrValue—Item string value

IsValueReady 222:

HRESULT is ValueReady([out]BOOL *pbValue)

Return Value:

pbValue—TRUE (data ready), FALSE(data not ready)

SetItemListener 224:

HRESULT setItemListener([in] IDispatch *newItemListener)

Return Value:

newItemListener—Pointer to the listener interface

PokeStringValue 226:

HRESULT PokeStringValue([in] BSTR *newValue)

Return Value:

NewValue—string value to poke

PokeIntValue 228:

HRESULT PokelntValue([in] int newValue)

Return Value:

newValue—Integer value to poke

PokeFloatValue 230:

HRESULT PokeFloatValue([in] float newValue)

Return Value:

newValue—float value to poke

With reference to FIG. 8, the IOItemListener Interface 192 includes anItemStatus 232 method call that returns a status of an indicated item.

HRESULT itemStatus([in] int ItemId, [in] int ItemStatus);

Parameters:

ItemId—Specify a specific item id#

ItemStatus—giving status of item

An itemData 234 method is a call for an identified data item.

HRESULT itemData([in] int ItemId,[in] VARIANT *pvarData);

ItemId—Specify a specific item id

pvarData—different type of data

With reference to FIG. 9, the HCI component interface Ioutpost 172 forthe RDB 180 includes the following methods.

Open 240:

HRESULT Open([in] int Scheme,[in] BSTR bstrUsername,[in] BSTRbstrPassword,[in] BSTR bstrOutpost,[in] BSTR bstrPort,[in] BSTRbstrHandler, [in] int iPollstate,[out] SCODE *pError)

Close 242:

HRESULT Close([out] SCODE *pError)

Return Value:

pError—(S_OK—successful)

Send 244:

HRESULT Send([in] VARLANT *pvarBuff, [in] int iSize, [in] intiRequestID, [in] int iSenderID,[out] SCODE *pError)

Parameters:

pvarBuff—pointer to data

iSize—length of data

iRequestID—a unique request ID

iSenderID—a unique sender ID

Return Value:

pError—(S_OK—successful)

GetSessionID 246:

HRESULT GetSessionID([out] int *piID,[out] SCODE *pError)

Return Value:

piID—return the session ID

pError—(S_OK—successful)

SetPollState 248:

HRESULT SetPollState([in] int iState,[out] SCODE *pError)

Parameters:

iState

Return Value:

pError—(S_OK—successful)

GetPollState 250:

HRESULT GetPollState([out] int *piState,[out] SCODE *pError)

Return Value:

piState

pError—(S_OK—successful)

Turning to FIG. 10, the following methods are implemented in theIoutpostSessionListener Interface 176 of the CrdbSession object 174.

SessionCreated 260:

HRESULT sessionCreated([in] int sessionID)

Parameters:

sessionID—created session ID

SessionCreateFail 262:

HRESULT sessionCreateFail([in] int errorCode)

Parameters:

ErrorCode—

SessionClosed 264:

HRESULT sessionClosed ([in] int sessionID)

Parameters:

sessionID—ID of the closed session

Receive 266:

HRESULT receive ([in] int sessionID,[in] VARIANT *buffer,[in] intbufferSize,[in] int requestID,[in] int senderID)

Parameters:

sessionID—session ID

buffer—pointer to data

buffersize—length of data

requestID—request ID

senderID—sender ID

SendFail 268:

HRESULT sendFail ([in] int sessionID,[in] int reason,[in] intrequestID,[in] int senderID)

Parameters:

sessionID—ID of failed session

reason—reason for failing

requestID—request ID

senderID—sender ID

SendSucceed 270:

HRESULT sendSucceed ([in] int sessionID,[in] int requestID,[in] intsenderID)

Parameters:

sessionID—ID of succeed session

requestID—request ID

senderID—sender ID

SessionError 272:

HRESULT sessionError ([in] int errorCode,[in] BSTR errorMessage)

Having described the creation of connections and interfaces between theDE 182 and a corresponding data source, attention is now directed toFIG. 11 that depicts a sequence of calls and actions between a client(portal server HCI 170) and a plant server 178 over an established httpconnection. Such a connection is created for data transmitted betweenthe HCI 170 and web server 178 and is maintained for each windowset thatdisplays on the client browsers. During stage 300, the HCI 170 transmitsa server information request that gets the size of each packet theserver can handle and the version of the protocol. The serverinformation request follows the general format depicted below.ServerInfoRequest: TYPE_HEADER + SERVER_REQUEST TYPE_HEADER { DWORDLength; DWORD Type; ( SERVER_REQ =1) DWORD RequestID; (0) DWORDSendderID; (0) DWORD ErrorCode; DWORD Reserved[4]; } SERVER_REQUEST {char clientInfo[128]; (“OutpostConnObject “) }

In response, at step 302 the server 178 issues a server informationresponse. The server 178's response follows the following format. ServerInfo Reply: TYPE_HEADER+ SERVER_RPLY TYPE_HEADER { DWORD Length; DWORDType; ( SERVER_REPLY=1 ) DWORD RequestID; (0) DWORD SendderlD; (0) DWORDErrorCode; DWORD Reserved[4]; } SERVER_RPLY { DWORD MaxRequestSize;DWORD MaxReplySize; DWORD ProtocolVersion; }

Thereafter, at step 304 the client HCI 170 issues a create sessionrequest to the server 178 that follows the following format.CreateSessionRequest: TYPE_HEADER + CREATE_SESSION_REQUEST TYPE_HEADER {DWORD Length; DWORD Type; ( CREATE_SESSION=2) DWORD RequestID; (0) DWORDSendderID; (0) DWORD ErrorCode; DWORD Reserved[4]; }CREATE_SESSION_REQUEST { char DstHandlerName[128]; (“WWRdbHandler”)DWORD ProtocolVersion; (1) }

In response, at step 306 the server 178 issues the following reply.CreateSessionReply: TYPE_HEADER+CREATE_SESSION_REPLY TYPE_HEADER { DWORDLength; DWORD Type; (CREATE_SESSION_RPLY=3) DWORD RequestID; (0) DWORDSendderID; (0) DWORD ErrorCode; DWORD Reserved[4]; }CREATE_SESSION_REPLY { DWORD HandlerId; DWORD SessionId; }

At step 308 the client HCI 170 issues a connect request to the server178 generally as follows. WW_HEADER_INFO + WW_CONNECT_INFOWW_HEADER_INFO { DWORD type; (WW_CONNECT_INFO_TYPE=1) DWORD len; }WW_CONNECT_INFO { DWORD ConnType; DWORD ConnId; Char Node[128]; //client actually sends 128 bytes to server regardless of the actual datasize Char App[128]; Char Topic[128]; }

Next, during step 310 the client HCI 170 registers with the server 178.Registration establishes particular data items for which the client HCI170 wishes to receive updated values. WW_HEADER_INFO + WW_REGISTER_INFOWW_HEADER_INFO { DWORD type; (WW_REGISTER_INFO_TYPE=3) DWORD len; }WW_REGISTER_INFO { DWORD ConnId; char Item[64]; DWORD ItemId; };

Thereafter, at step 312 the client HCI 170 issues periodic requests tothe server 178 for updates with regard to particular registered items.An example of such a request follows. WW_HEADER_INFO + WW_ADVISE_INFOWW_HEADER_INFO { DWORD type; (WW_ADVISE_INFO_TYPE=5) DWORD len; }WW_ADVISE_INFO { DWORD ConnId; DWORD ItemId; } WW_HEADER_INFO +WW_REQUEST_INFO WW_HEADER_INFO { DWORD type; (WW_REQUEST_INFO_TYPE=7)DWORD len; } WW_REQUEST_INFO { DWORD ConnId; DWORD ItemId; };WW_HEADER_INFO + WW_POKE_INFO WW_HEADER_INFO { DWORD type;(WW_POKE_INFO_TYPE=8) DWORD len; } WW_POKE_INFO { DWORD ConnId; DWORDItemId; WORD PokeId; WORD PointType; PTVALUE PointValue; }

It is noted that the above call sequences are merely exemplary. As thoseskilled in the art will readily appreciate, there are many ways in whichto carry out the setup and update request sequence. Furthermore, thepresent example represents a pull strategy. However, in an alternativeembodiment, the server 178 pushes changed data to a client HCI 170.

In a base system embodying the present invention, users select from anextensible set of data sources, but are confined to choose from acurrent set of data types. However, in an enhanced version of thepresent invention, a standardized data input interface incorporated intoa toolkit (providing a development template) enables third party dataproviders to develop customized data handlers for new/proprietary datatypes. These customized data handlers render standardized data to thedata exchange component 182. In this extensible embodiment of thepresent invention wherein the concept of an open architecture isbroadened to include adding new data handlers, the data handlers arestored on the portal server system and are registered within a list ofavailable handlers selectable by users. Thus, the portal server 100'sfunctionality is extendable in this case to handle new data formats thatwere not incorporated within an initial release of the portal server 100system.

Turning now to FIG. 12, in a particular exemplary embodiment of theinvention, a new portal server framework is provided in the form of aframework web service handler 400 that exposes a set of methods allowingclient applications 410 to get a list of available data sources and/ordata types from a data provider registry 420 that stores a set ofentries corresponding to both external/third-party data provider Webservice handlers 425 (created from a development toolkit) and internallydeveloped data provider Web service handlers 427. Each of the dataprovider web service handlers (425 and 427) in turn connects to datasources that are associated with that data type. When a new handler orsource is added by means of a configuration interface similar to the onedepicted in FIG. 4, a new entry is added to the data provider registry420 corresponding to the new provider.

It is noted that multiple web service handlers can exist that implementa same data type. Thus, the selection of a particular web servicehandler is driven by the data source configured by the user in a mannersuch as the one previously disclosed in FIG. 4 and discussed hereinabove. However, in view of the potentially large number of data handlerssupported by the present architecture, a new interface arrangement, suchas a drop-down list of handlers, may be desired to avoid the presence oftoo many tabs (as shown in FIG. 4). A data source configuration database430 supplies a set of ASP pages 432 facilitating selection of aparticular data source/handler. Thereafter the clients 410 connect to aparticular data provider, via the framework web service handler andretrieve a set of methods that are supported by the selected provider.Third parties implement their own data provider handlers as web servicesand register with the framework web service handler 400 to enable theclients 410 to access the third-party data provider. The framework webservice handler 400 enforces a common set of interfaces that each dataprovider web service handler (e.g., 425 and 427) implements to plug dataproviders of a particular type into the framework Web service handler400.

All client applications 410 communicate with data sources/providers(e.g., data providers 435 and 437) through the framework web servicehandler 400 on a set of standard interfaces (methods) which in turn areconveyed over a standard communication protocol. The well-known SOAP(simple object access protocol) standard is an exemplary choice for astandard communication protocol between client 410 and the framework webservice handler 400. SOAP may also be used for the framework web servicehandler 406 to data provider Web service handler communications. Toleverage SOAP technology, available MICROSOFT COM components are used toparse SOAP messages. On the server side an ISAPI dll is implemented onthe framework web service handler 400 to handle all the SOAP requestsfrom the clients 410, to process and dispatch requests to the dataprovider web services. The session item and dispatcher classesimplemented within the framework web service handler 400, and theconnection and command classes of clients 410, are discussed furtherherein below.

In an alternative embodiment of the invention discussed hereinabove withreference to FIG. 12, data sources and their associated handlers areidentified within the data provider registry 420 according to an XMLschema summarized in FIG. 13. An ID field 450 stores a unique number foreach data provider/handler. This is a system-generated number that isassigned when the data provider/handler record is created and storedwithin the data provider registry 420. A name field 452 holds the nameof the data provider and is designated during configuration by thesubmitter of the new data provider record (e.g., SQL Provider, AlarmProvider). A description field 454 holds the description of the dataprovider and is also designated by the author of the data providerrecord. A WSDL field 456 holds a value designating a location of the WebService Definition Language file that describes the interface/methodsfor the data handler associated with this particular data source. AnExtended WSDL field 458 holds supporting information for the WSDLreferenced in the WSDL field 456. A connection string field 460 holdsparticular information to facilitate making a connection to the datahandler through which the identified data provider furnishesinformation. The connection string field 460 holds, for example, initialparameters, username, password, etc.

Having described exemplary fields for a data provider record, attentionis directed to FIGS. 14 and 15 wherein exemplary GUI displays areprovided for a data provider to register with the framework web servicehandler 400. When a data provider is implemented (potentially by a thirdparty), steps are taken to expose the data provider to the clients 410via the framework web service handler 400. This is accomplished throughregistration of the data provider with the framework web service handler400. Basically, the framework web service handler 400 provides a pagesupporting registration to populate the fields of the schema summarizedin FIG. 13. By way of example, the “new provider” enters the name of thedata provider, a description identifying the type of provider, a URL tothe provider Web Service Description Language, connection string, etc.Turning to FIG. 15, one of the primary differences between the enhancedsystem registration process and the one set forth above with referenceto FIGS. 3 and 4 is the ability of a provider to designate a new datatype handler during the data provider registration. This is accomplishedby selecting the “My Provider” option on the opening data registrationGUI display set forth in FIG. 15. Once registered with the framework webservice handler 400 (the portal server), the data provider informationis furnished to clients 410 when the clients invoke a BrowseDS methodwhich retrieves and displays data sources.

Turning to FIGS. 16 and 17, a set of method calls are incorporated intoa connection object 500 and command object 520. In an embodiment of theinvention, the browser clients 410 provide COM wrappers that abstractthe applications from SOAP implementation. The wrappers expose simpleinterfaces allowing client applications 410 to communicate with theframework web service handler 400 and data providers via the dataprovider web service handlers. The connection object 500 and commandobject 520 are such wrappers. The method calls identified for each arediscussed further herein below with reference to the browser clientinterface supported by the framework web service handler 400.

Turning now to FIG. 18, a set of methods are identified that aresupported by the framework web service handler 400. A browseDS method550 is called by the clients 410 requesting enumeration of the datasources presently supported by the framework web service handler 400. Alist is returned containing a set of available provider information. Theset of provider information includes the content of the provider recordsdescribed herein above with reference to FIG. 13. A connectDS method 552is called by the clients 410 and returns a URL for a file(wwdbintf.wsdl) that describes all methods of the command object 520that the data provider supports. A closeDS method 554 is called by theclients 410 to close a connection between a calling client and theframework handler 400.

Turning to FIG. 19, a sequence diagram depicts an exemplary set of stepsexecuted between the clients 410 and the framework web service handler400 during the course of a user session. At step 600 the clientapplication issues a “CoCreate” request to instantiate the connectionobject 500. Thereafter, at step 602 the client application issues aninitialize command to initialize the connection object 500. Inparticular, the client object creates and initializes the MICROSOFT SOAPobject to handle SOAP requests. At step 604 the client issues aGetDataProviderList command to the connection object 500. The connectionobject during step 605 invokes the browseDS method 550 on thewwservicehandler interface of the framework web service handler 400. Theframework handler 400 returns for display on the client application'suser interface a list of available data providers.

After a user has selected a particular one of the available dataproviders, during step 606 the client application issues aConnectToDataSource command to the connection object 500. Next, duringstep 607 the connection object 500 issues a connect request to thewwservicehandler interface. The connection request includes parametersidentifying the data source to which the client application wishes toestablish a connection.

After establishing a connection, the client application issues aCoCreate command during step 608 to instantiate the command object 520.Thereafter, at step 610 the client application issues a cSelect call tothe command object 520 to retrieve a record set from the previouslyselected data provider (source). In the exemplary embodiment therecipient of the request is a SQL provider.

At step 612, the command object 520 invokes the get_DataSrcWSDL methodon the connection object 500 to obtain the language definitions forcommunicating with the selected data source. Thereafter, at step 614 thecommand object 520 invokes the get ConnectionID method on the connectionobject (which in turn calls ConnectDS) to obtain the connection ID usedto fill an ID parameter when making calls to the framework web servicehandler 400. Thereafter, during step 615 the command object 520 issuesrequests on behalf of the client application on an establishedconnection to the selected data provider.

After completing a session, at step 616 the client application issues aCloseConnection command to the connection object 500. The above sequenceof steps is intended to provide an exemplary use of the methodssupported by the connection object 500 and command object 520. Thoseskilled in the art will readily appreciate that both the supportedmethods and the sequence of steps disclosed in FIGS. 16, 17, 18, and 19are exemplary and that a variety of alternatives are contemplated inother embodiments of an extensible manufacturing/process control portalserver system incorporating the present invention.

Having described a client application-side connection architecture inaccordance with an alternative version of a manufacturing/processcontrol portal server embodying the present invention, attention is nowdirected to the data-provider interface of the portal serverarchitecture. Turning to FIG. 20, a set of interfaces are identifiedwith associated methods supported by the interfaces. The framework webservice handler 400, in an embodiment of the present invention, is anISAPI dynamically linked library that intercepts and processes allrequests from the client 410. For each request intercepted by accDataMarshaller class 620, a dispatcher class 622 and a sessionItemclass 624 implemented by the framework handler 400 process and thendispatch the request to a particular data provider handler.

FIG. 20 depicts an exemplary relationship between these three objectclasses within the framework web service handler 400. The framework webservice handler 400 includes a pool of worker threads to handle requestsfrom clients. The CCDataMarshaller class 620 takes a message from aclient and uses a well-known MICROSOFT SOAP READER component to parsethe message and call the appropriate method in the Dispatcher class 622.Each connection to a data source will have a SessionItem class 624 toprocess and handle calls to a particular data provider. The SessionItemclass 624 in turn calls an interface to the designated data provider.

FIG. 21 identifies a set of methods implemented within a data providerhandler implementing the present invention. This interface definitionrepresents an exemplary set of methods that are implemented upon dataprovider handlers to communicate with the framework web service handler400 and respond to client requests passed by the framework web servicehandler 400 to the provider handlers. A data provider handler exposesthe pSelect method 632 only if it is able to handle SQL statements.Otherwise the data provider handler exposes the pOpenRowSet method 634which works with a single table at a time. The remaining methods aregenerally needed to implement any type of handler. The interface methodspecifications are provided herein below.

PConnect 630 is the first call the framework initiates to establish aconnection with the provider.

pConnect([in] BSTR UserID, [in] BSTR Password, [in] BSTR

ConfigParmxml, [out, retval] int *ConnID)

Parameters:

UserID—User ID that provider needed for authentication

Password—Password needed for authentication

ConfigParmxml—Connection string. Provider will provide a mechanism toobtain from user

ConnID—This ID will be used for all subsequent calls pertaining to thisconnection

Pselect 632 is called by the framework 400 to retrieve a record set. Aprovider should only expose this method if supports SQL commands.

pSelect([in] int ConnID, [in] BSTR Statement,[in] int MaxRecord, [out,retval] BSTR *xmlRowSet)

Parameters:

-   -   ConnID—Specify which connection to perform this operation    -   Statement—SQL statement    -   MaxRecord—0: framework only wants the schema back; −1: wants to        get all rows; >0: wants certain number of records    -   XmlRowSet—returned set of records in xml format        pOpenRowSet 634 is called by the framework to retrieve a record        set. A provider exposes this method if it supports working with        a single table.        pOpenRowSet([in] int ConnID, [in] BSTR xmlCondition,[in] int        MaxRecord, [out,retval] BSTR *xmlRowSet)

Parameters:

-   -   ConnID—specify which connection    -   xmlCondition—condition specifies how to return data in xml        format    -   MaxRecord—0: framework only wants the schema back; −1: wants to        get all rows; >0: wants certain number of record    -   XmlRowSet—returned set of records in xml format        PClose 636 closes a current row set.        pClose([in] int ConnID)        PDelete 638 deletes a record in a current record set.        pDelete([in] int ConnID, [in] BSTR xmlCondition)

Parameters:

-   -   ConnID—Specify which connection    -   XmlCondition—Specify how to delete a record in current record        set. Data in xml format.        PInsert 640 inserts a record into a currently open record set.        pInsert([in] int ConnID, [in] BSTR xmlCondition)

Parameters:

-   -   ConnID—Specify which connection    -   XmlCondition—Specify how to update a record in xml format        PNextRecordSet 642 retrieves a next set of records.        pNextRecordSet([in] int ConnID, [in] int MaxRecord, [out,retval]        BSTR *xmlRowSet)

Parameters:

-   -   ConnID—Specify which connection    -   MaxRecord—maximum number of records framework will accept    -   XmlRowSet—returned set of records in xml format        PUpdate 644 updates a record in a currently open record set.        pUpdate([in] int ConnID, [in] BSTR xmlCondition)

Parameters:

-   -   ConnID—Specify which connection    -   XmlCondition—Specify how to update a record in xml format.        PPreviousRecordSet 646 retrieves a previous record set.        pPreviousRecordSet([in] int ConnID, [in] int MaxRecord,        [out,retval] BSTR *xmlRowSet)

Parameters:

-   -   ConnID—Specify which connection    -   MaxRecord—maximum number of records framework will accept.    -   XmlRowSet—returned set of records in xml format        PFirstRecordSet 648 retrieves the first record set.        pFirstRecordSet([in] int ConnID, [in] int MaxRecord,        [out,retval] BSTR *xmlRowSetl)

Parameters:

-   -   ConnID—Specify which connection    -   MaxRecord—maximum number of records framework will accept    -   XmlRowSet—returned set of records in xml format        PLastRecordSet 650 retrieves the last record set.        pLastRecordSet([in] int ConnID, [in] int MaxRecord, [out,retval]        BSTR *xmlRowSetl)

Parameters:

-   -   ConnID—Specify which connection    -   MaxRecord—maximum number of records framework will accept    -   XmlRowSet—returned set of records in xml format        PDisconnect 652 releases a connection.    -   pDisconnect([in] int ConnID)

In the above set of exemplary interface methods, it is noted that thepSelect, pNextRecordSet, pOpenRowSet, pFirstRecordSet, pLastRecordSet,and pPreviousRecordSet methods are expected to return a rowset in XMLformat. The following represents an exemplary XML schema for returningXML rowset data. <xml xmlns:s=“ww-dataprovider-schema”xmlns:dt=“ww-datatype-definition”xmlns:rs=“urn:schemas-wonderware-com:rowset” xmlns:z=“#RowsetSchema”><s:Schema id=“RowsetSchema”> <s:ElementType name=“row”content=“eltOnly”> <s:AttributeType name=“AppID” rs:number=“1”><s:datatype dt:type=“int” dt:maxLength=“4”/> </s:AttributeType><s:AttributeType name=“Title” rs:number=“2”> <s:datatypedt:type-“string” dt:maxLength=“40” /> </s:AttributeType></s:ElementType> </s:Schema> <rs:data> <z:row AppID=“1”Title=“Charting”/> <z:row AppID=“2” Title=“Reporting” /> <z:rowAppID=“3” Title=“Data Grid”/> </rs:data> </xml>

The returned XML has two sections. The top section is a schemadescribing how the data is to be returned. Each attribute elementrepresents a column and describes the column name and number. Thesub-element describes the data type and the maximum length of the field.The bottom section is the actual data in the format defined by theschema. The row element has attributes specifying the name of thecolumn, column number, data type, and the maximum length of the datafield. Schema only need be returned in the pSelect or pOpenRowSet call.Subsequent calls such as pNextRecordSet only need to return the data.When there is no more data to return, the provider returns the followingxml message. <xml> <no-more-row/> </xml>

Turning now to FIG. 22, an exemplary SQL provider handler classstructure is illustratively depicted. In an embodiment of the presentinvention a SQL Provider handler uses ADO to access a database. The SQLprovider handler supports the pSelect and most of the above identifiedprovider interface methods. However the SQL provider does not supportthe pOpenRowSet method. The SQL provider handler has an ASP page as itsservice handler that calls into a COM component. FIG. 22 depicts therelationship between classes in the COM component.

Illustrative embodiments of the present invention and certain variationsthereof have been provided in the Figures and accompanying writtendescription. The present invention is not intended to be limited tothese embodiments. Rather the present invention is intended to cover thedisclosed embodiments as well as others falling within the scope andspirit of the invention to the fullest extent permitted in view of thisdisclosure and the inventions defined by the claims appended hereinbelow.

1-11. (canceled)
 12. An industrial control system, comprising: aplurality of components cooperating to provide industrial processcontrol, the components including a process control component; and anetworked server including an interface that facilitates bi-directionalcommunications between clients and at least one web service associatedwith at least one of the plurality of components.
 13. The system ofclaim 12, wherein the at least one web service is associated with a dataprovider for one of the plurality of components.
 14. The system of claim12, wherein the interface is an open standards Web Services DescriptionLanguage (WSDL) that describes how to interact with the web service inorder to provide clients access to at least one of the plurality ofcomponents of the industrial control system.
 15. The system of claim 14,wherein the WSDL describes an XML format for control system requests andresponses.
 16. The system of claim 12, further comprising a SimpleObject Access Protocol (SOAP) to communicate with the interface, atleast one of the plurality of components, and the web service.
 17. Thesystem of claim 12, further comprising a discovery component tofacilitate locating data sources associated with the plurality ofcomponents.
 18. The system of claim 12, wherein the web service isoperated from the networked server.
 19. The system of claim 12, whereinthe networked server is a portal server.
 20. A method for providingaccess to information, in a variety of forms, relating to the operationof an industrial controller environment, the method comprising the stepsof: configuring a web service for providing access to at least onecomponent in an industrial control process; defining an interface forcommunicating with the web service; employing an XML-based protocol forcommunicating with the interface; and interacting with the at least onecomponent across a network to manage the industrial control process viathe interface and the XML-based protocol.
 21. The method of claim 20,further comprising configuring the interface via a Web ServiceDescription Language (WSDL) and employing Simple Object Access Protocol(SOAP) as the XML-based protocol.
 22. The method of claim 20, whereinthe web service is associated with a portal server.
 23. The method ofclaim 20, wherein the web service is associated with a data handler forproviding data access to the at least one component in the industrialcontrol process.
 24. The method of claim 23, wherein the data access isbidirectional.